It is often useful to log information about events that occur in computer systems. The events could be any occurrence (e.g. an action or a process) about which information may subsequently be useful. Furthermore, the information that is logged could be of any suitable type that may be useful.
Tracing is an example of logging which is used to record information, in a trace log, about a program's execution. The information may, for example, be used by programmers for debugging purposes. The information contained in the trace log may also be used by system administrators and/or technical support personnel to diagnose problems with software. Some examples of events that may cause data to be stored in a trace log are: an exception being thrown by a program, reading data from a memory, changing the value of a variable, etc. Each of the events will occur at a particular time, and the trace log stores a timestamp with each event to indicate a time of the event. Therefore, by analysing the data stored in the trace log, a time flow of events in the computer system can be identified.
For each event, an entry can be stored in a store, i.e. in the trace log. As an example, the store may be configured to store 48-bit entries for events. FIG. 1 shows an example of an entry 100 which includes 48 bits, wherein the entry includes an 18-bit timestamp field 102, a 6-bit ID field 104 and a 24-bit data field 106. The ID field 104 and the data field 106 may collectively be referred to as the “payload” of the entry, such that the entry includes a timestamp and a payload. When an event occurs which is to be logged, a timestamp for the event can be determined (e.g. based on a clock in the computer system). In this example, the timestamp includes 18 bits which are to be stored in the timestamp field 102 for the event. The ID field 104 includes an indication of the processing element (e.g. a CPU, signal processing unit or other processing element within the computer system) that caused the event to occur. The data field 106 includes data relating to the event that occurred, e.g. to indicate that an exception has occurred, to indicate that a variable has changed its value, or any other suitable information relating to an event.
The frequency with which events occur can be different for different computer systems, and can vary over time. For example, a Digital Signal Processor (DSP) may operate, causing events to occur very quickly while data signals are being transmitted or received from or to a computer system, but the frequency with which events occur may decrease when the computer system ceases transmitting or receiving the signals.
A timing clock may be used to determine the timestamps for the events to be logged in the store. Using a faster timing clock increases the resolution of the timestamps which allows greater precision to be identified in the timing of events, but causes the timestamp to “wrap around” more frequently. Such a timestamp is an example of a modular arithmetic system wherein numbers are said to “wrap around” when they reach a certain value known as the modulus. For example, if 18 bits are used for the timestamps for the events, as shown in FIG. 1, then the modulus is 218, that is 218 unique timestamps are available, and after 218 timer ticks, the timestamp will cycle back to the first value. That is, with an n-bit timestamp and a timing clock frequency of f, the timestamp of an event at time t will be the same as the timestamp of an event at time
  t  +                    2        n            f        .  The timestamp “wraps around” when it increments from its maximum value to return back to its minimum value, e.g. a 2n-bit timestamp will wrap around when it increments from a value of 2n−1 back to zero.
As an example, a signal processing unit such as a DSP will use a relatively high frequency timing clock for the event logging because events occur very quickly in signal processing units and the timestamps preferably have enough resolution to indicate the relative timings of events in the computer system. For example, the frequency of the timing clock may be 350 MHz, which means that with a 218-bit timestamp, the timestamp will wrap every 749 μs
      (                  i        .        e        .                                  ⁢                              2            18                                350            ⁢                                                  ⁢            MHz                              =              749        ⁢                                  ⁢        µ        ⁢                                  ⁢        s              )    .This means that the timestamps may become ambiguous over a period of time greater than 749 μs. That is, if there is a period of at least 749 μs during which no events are logged, then the correct time flow of the events in the trace log is lost. It is noted that the events may occur at irregular intervals. One way to keep unambiguous timestamps over a greater period of time and to reduce the likelihood of losing the correct time flow in this way, is to increase the number of bits used for the timestamp. For example, if 24 bits are used for the timestamp, with a timing clock at 350 MHz, then the timestamp will wrap every 47.9 ms
      (                  i        .        e        .                                  ⁢                              2            24                                350            ⁢                                                  ⁢            MHz                              =              47.9        ⁢                                  ⁢        ms              )    .Therefore there would have to be a much longer period (64 times as long) during which no events occurred for the timestamps to become ambiguous and for the correct time flow of the events to be lost.
However, there are often tight constraints on the amount of data that can be stored in the trace log, and so it may be detrimental to increase the size of each entry to allow for more timestamp bits. This is particularly the case in computer systems in which events occur at high frequencies, such as in computer systems including signal processing units. So it may not be beneficial to increase the number of bits in each entry that is stored in the trace log. Therefore, if the number of bits used for the timestamp is increased then the number of bits that can be used in the payload of the entry (i.e. in the ID field and the data field) would be reduced. However, this might not be desirable because fewer payload bits would mean that less information for an event can be stored in an entry.
So, when setting the format of the entries for events, there is a trade-off between the number of timestamp bits and the number of payload bits within the entries.